home *** CD-ROM | disk | FTP | other *** search
/ Language/OS - Multiplatform Resource Library / LANGUAGE OS.iso / tcl / workshop / tcl93pr1.lha / tcl93-proceedings2 / futures / session2 < prev    next >
Text File  |  1993-06-15  |  13KB  |  283 lines
  1. Article 4771 of comp.lang.tcl:
  2. Path: chemabs!malgudi.oar.net!caen!nigel.msen.com!sdd.hp.com!cs.utexas.edu!swrinde!gatech!usenet.ins.cwru.edu!agate!cory.Berkeley.EDU!craigf
  3. From: craigf@cory.Berkeley.EDU (Craig Federighi)
  4. Newsgroups: comp.lang.tcl
  5. Subject: Tcl Future Directions Session #2 Notes
  6. Date: 14 Jun 1993 21:45:04 GMT
  7. Organization: University of California, Berkeley
  8. Lines: 269
  9. Message-ID: <1virh0$1iv@agate.berkeley.edu>
  10. NNTP-Posting-Host: cory.berkeley.edu
  11.  
  12. These are the notes from the second "future directions" session at the
  13. Tcl/Tk conference at Berkeley, June 10-11 1993.  Other Berkeley people
  14. have been posting (or will post) notes for the other three sessions.
  15. The focus of this session was managing extensions to Tcl/Tk.
  16.  
  17.        Tcl Future Directions Session #2, Thursday June 10 4:00-5:30
  18.        ------------------------------------------------------------
  19.        Notes taken by Craig Federighi.
  20.  
  21. Managing Extensions
  22. ----------------------------------
  23.  
  24. John Ousterhout led a discussion on managing Tcl and Tk extensions, and 
  25. proposed several possible solutions.  The following outline is based on his 
  26. notes.  Lines tagged with a >> are not part of the official handout.
  27.  
  28. 1. Introduction
  29.     Goal:
  30.         * Make it easy to mix and match various extensions to Tcl and Tk
  31.           (both C code and Tcl scripts)
  32.     Problems:
  33.         * Name conflicts
  34.         * Installation is non-uniform and clumsy
  35.         * Proliferation of binaries
  36.     Solutions:
  37.         * Naming conventions
  38.         * Installation conventions
  39.         * Dynamic Linking, Better auto-loading
  40.         
  41. 2. Naming Conventions
  42.     Problem:
  43.         * Each person assumed he/she is the only one building 
  44.           extensions
  45.         * Different packages use same names for global variables
  46.           and commands, e.g. "send"
  47.     Possible Solution #1: module mechanism
  48.         * Tcl provides mechanism for static variables and procedures
  49.             >> these are invisible outside of the module
  50.         * Still doesn't solve problem for new commands and global
  51.           procedures.
  52.             >> Disagreement was actually expressed about this assertion.
  53.                A brief description of a module mechanism that eliminates
  54.                this problem was discussed.  See below.
  55.     Possible solution #2:  single command with extensions
  56.         * Like string command: "string index", etc.
  57.         * Still need to find a unique command name, unique
  58.           variable names.
  59.     Possible solution #3:
  60.         * For each application or extension, pick a short prefix: e.g.:
  61.             expect_
  62.             xp_
  63.             tk_
  64.             dp_
  65.         * Use prefix in all global names (variables, commands, procedures):
  66.             xp_send
  67.             tk_priv
  68.             dp_rpc
  69.         * Suggestions for uniformity:
  70.             - Only one underscore per name
  71.             - Use capitalization at internal word boundaries
  72.         * Examples: tk_menuBar, not tk_menu_bar or tk_menubar
  73.             >> Here a significant debate began
  74.               - The group decided that developers could do whatever they
  75.                 wanted after the first underscore.  J.O. would simply
  76.                 offer the mixed case naming as a suggestion.
  77.               - Developers that used proper prefixing for their modules
  78.                 would be considered good members of the community
  79.               
  80.             >> Internal identifiers:
  81.               - Several suggestions were put forward for internal (private)
  82.                 identifiers within a module.  Suggestions:
  83.                   - _tk_foo
  84.                   - tk:foo
  85.                 J.O. will pick one and offer it as a suggestion.
  86.             >> Non-uniformity, ugliness, and end users
  87.               - Many participants were not entirely satisfied by the prefix
  88.                 scheme.  Specifically:
  89.                   - Some Tcl/Tk commands seem to have an unfair advantage,
  90.                     i.e. the button widget in Tk is "button," not "tk_button,"
  91.                     while a button in a separate package would have to
  92.                     have a prefix.
  93.                   - Some expressed distaste at having to type and read
  94.                     code filled with extensions.
  95.                   - A few participants expressed concern about having to
  96.                     make end users of commercial products deal with a bunch
  97.                     of prefixes.
  98.             >> Modules revisited
  99.               - One participant (me) pointed out that a Module interface
  100.                 that supported renaming (such as used in Modula 3) could
  101.                 eliminate most of the above problems.  The idea is as follows:
  102.               Imagine three packages: DP (UCB Tcl-DP), Expect, and Tk.
  103.               Authors of these packages could write code like:
  104.               module DP {
  105.                 # External variables
  106.                 xvars conn
  107.                 
  108.                 # externally visible proc
  109.                 xproc Send {a1 a2} { ... }
  110.                 
  111.                 # private (internal proc)
  112.                 proc DoSomething {} {...} 
  113.               }
  114.               
  115.               The client can use modules as follows:
  116.               import Tk.all Expect {DP.Send as RPC}
  117.               
  118.               # client calls:
  119.               
  120.               # Tk.all means all Tk commands are imported to be called
  121.               # without a module prefix:
  122.               button .foo
  123.               
  124.               # Expect package is imported so that external identifiers
  125.               # must be prefaced with the module name
  126.               Expect.Send "a string"
  127.               
  128.               # The Send command is imported from  Tcl-DP under the
  129.               # name RPC and can be called without a prefix
  130.               RPC $host ls
  131.               
  132.               Now suppose that someone on the net releases a new package
  133.               that also used the prefix "DP."  We're still okay:
  134.               
  135.               import Tk.all Expect {"UCB-DP" as DP} {"Other-DP" as ODP}
  136.               DP.Send ...
  137.               ODP.do ...
  138.               
  139.               Several participants liked this approach.  J.O. felt that
  140.               the prefix scheme was much simpler and reduces renaming-induced
  141.               confusion when reading others code.  We were all encouraged
  142.               to read the source code for "sh" for a clear illustration
  143.               of this problem.
  144.     Classes in Prefixes:
  145.         * Establish a central registry for prefixes.
  146.             >> J.O. felt that this wouldn't be necessary for a while,
  147.                but at least one participant thought that the registry
  148.                should be established immediately.
  149.     Solution #4:  Object-oriented commands
  150.         * Like Tk widgets
  151.         * One command to create object, returns object name: 
  152.             "button .b"
  153.         * Use object name as command name, put action as 
  154.           first argument: ".b invoke"
  155.         * Avoids command space pollution: only one new command
  156.           (plus object commands).
  157.         * Can provide uniform actions for many different kinds of objects.
  158.         * Must allocate unique object names (similar to choosing unique
  159.           prefix).
  160.         >> Participants pointed out that unique names must be generated
  161.            for object names.  The group concluded that the module prefix
  162.            should be used as a prefix in all dynamically generated object
  163.            identifiers.  Tk reserves the "." prefix for object instance 
  164.            names.
  165.            
  166. 3. Installation
  167.     Scripts are easy:
  168.         * Put .tcl files in a directory.
  169.         * Create "tclIndex" file
  170.         * Add directory to "auto_path"
  171.           >> the environment variables "TCL_LIBRARY" and "TK_LIBRARY"
  172.              serve this purpose
  173.     C code is hard
  174.         * Where to put source code?
  175.         * Must compile extensions.
  176.         * Must add code to "wish" main program by hand.
  177.         * Must make new binary.
  178.         * Different packages install differently.
  179.         * Incompatible versions
  180.  
  181.     Source Code Management
  182.         * Pick a directory to hold sources for Tcl, Tk, and 
  183.           extensions.
  184.         * Each package or application is a subdirectory of this directory:
  185.             /usr/local/src/tcl:
  186.               tcl7.0
  187.               tk3.3
  188.               ...
  189.               expect2.1
  190.             >> under each package directory would be a lib/ include/ and
  191.                bin directory.
  192.             >> This will be set up so that all of the public headers, 
  193.                libraries, Tcl scripts, and binaries are installed in the 
  194.                appropriate places (e.g. /usr/local/bin).
  195.             >> Many expressed the need to support multiple architecture
  196.                environments.
  197.         * Keep version name in a directory name, so there can be multiple
  198.           versions of the same package.
  199.             >> have each module define a Tcl variable containing its version
  200.                number, e.g. expect_version, so that applications
  201.                can verify that they have the right version of 
  202.                included libraries.
  203.         * Use GNU "autoconfig" for configuration
  204.             >> A question was raised as to how the use of a GNU
  205.                tool might affect the distribution of commercial software.
  206.                J.O. wasn't sure what the legal specifics were, but believed
  207.                this probably isn't a problem.
  208.         * Create a library as well as an application
  209.  
  210.     Incorporating Extensions
  211.       In package:
  212.         * Define one C initialization procedure
  213.             Expect_Init
  214.             Dp_Init
  215.         * Init proc takes single argument: Tcl interpreter
  216.         * Calls Tcl_CreateCommand to create new command(s) for
  217.           package, performs and other initialization for package.
  218.       
  219.       To user package in application:
  220.         * Create procedure TclAppInit that calls all relevant 
  221.           initialization procedures, invokes application startup script.
  222.         * Link with relevant libraries.
  223.         * No need to modify main(): it calls Tcl_AppInit; Tcl and Tk provide
  224.           default Tcl_AppInit
  225.             >> Modules can insure that other modules that they depend on
  226.                are already initialized by calling their initprocs
  227.                explicitly before performing their own initialization.
  228.             >> Module writers should make sure that module initialization
  229.                procs are idempotent so that redundant init calls will
  230.                no cause problems.
  231.             >> Modules that need to execute shutdown code before app 
  232.                closes can register a Tcl proc to get called just after
  233.                the root window is destroyed.
  234.             >> No facility is currently provided for per-interpreter
  235.                initialization (for when an app creates multiple interpreters).
  236.             >> Clients wanting to make ambitious changes to Tk (e.g. change
  237.                the event loop) will need to write their own main() proc.
  238.             >> C++ users will need to compile main() under C++, or rename
  239.                the Tcl main to something else and then call it from a user
  240.                main() the was compiled under C++.
  241.               
  242. 4. Dynamic Linking
  243.     Goals:
  244.       * Avoid proliferation of binaries.
  245.       * More flexible: can add new packages dynamically without recompiling.
  246.       * Shared libraries save memory.
  247.     How?
  248.       * New Tcl command:
  249.         "load libraryName initProc"
  250.         >> It looks as if this man be further simplified to be just
  251.            "local libraryName"; the C initProc name will be automatically
  252.            derived from the name of the library.  e.g. libdp.a -> dp_Init()
  253.       * J.O. will solicit implementations for various systems and include
  254.         them in Tcl releases.
  255.       * Auto-load support (next slide).
  256.       * Must resolve differences in how to compile shared libraries 
  257.         for different systems.
  258.       >> J.O. surveyed the audience for Unix platforms that supported
  259.          dynamic linking.  Most (AIX, Solaris, OSF, HPUX, NeXTSTEP) support
  260.          "shared-libraries" but fewer (Solaris, NeXTSTEP...) support
  261.          dynamic linking.  SCO Unix supports neither.  This list obviously
  262.          needs to be further flushed out on the news group.
  263.          
  264. 5. Changes to Auto-Loading
  265.     Current approach:
  266.       * tclIndex files have fixed format:
  267.         tl_dialog    dialog.tcl
  268.         (proc name)  (file to source)
  269.       * index files are parsed, not evaluated.
  270.     New approach for Tcl 7.0
  271.       * Index files will be evaluated:
  272.           set auto_index(tk_dialog) \
  273.             "source $dir/dialog.tcl"
  274.       * Result: 3-4x faster, more flexible.
  275.         >> Faster because Tcl interpreter (written in C) used to do parse
  276.            rather than a parse routine written in Tcl.
  277.       * Should accommodate TclX style of auto-loading?
  278.         >> TclX guys said they would support Tcl7.0 form
  279.       * Can invoke "load" instead of "source" to auto-load
  280.         shared libraries.
  281.  
  282.  
  283.